perm filename LAST[CLS,LSP] blob
sn#856171 filedate 1988-04-21 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00009 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 ∂13-Apr-88 1032 Common-Lisp-Object-System-mailer corrections to Chapter 1
C00007 00003 ∂13-Apr-88 1318 Common-Lisp-Object-System-mailer Chapter 1 and 2 Last Chance Review
C00013 00004 ∂13-Apr-88 1414 Common-Lisp-Object-System-mailer Chapter 1 and 2 Last Chance Review
C00023 00005 ∂13-Apr-88 1435 Common-Lisp-Object-System-mailer Re: Chapter 1 and 2 Last Chance Review
C00026 00006 ∂14-Apr-88 0630 Common-Lisp-Object-System-mailer Re: Chapter 1 and 2 Last Chance Review
C00030 00007 ∂15-Apr-88 1046 Common-Lisp-Object-System-mailer Comment on CLOS
C00042 00008 ∂15-Apr-88 1345 Common-Lisp-Object-System-mailer CLOS comments
C00047 00009 ∂21-Apr-88 0707 Common-Lisp-Object-System-mailer some comments on CLOS
C00053 ENDMK
C⊗;
∂13-Apr-88 1032 Common-Lisp-Object-System-mailer corrections to Chapter 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Apr 88 10:32:50 PDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 381401; Wed 13-Apr-88 13:32:32 EDT
Date: Wed, 13 Apr 88 13:32 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: corrections to Chapter 1
To: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <19880413173208.7.SKEENE@JUNCO.SCRC.Symbolics.COM>
The section "Determining the Class Precedence List" has examples where
defclass is used to define classes, and the CPL is computed from those
definitions. However, the CPLs shown don't include standard-object
(they do include t). We should really fix this.
The table in Figure 1-1 has two columns, labelled "Predefined Common
Lisp Type" and "Class Precedence List". The first column heading isn't
right; actually, it is correct, but it misses the point. They are
Common Lisp types, but the important thing is that CLOS has classes
corresponding to those types. I think that column heading should be
simply "Classes" or "Predefined Classes" (since "Classes Corresponding
to Common Lisp Types" is too long).
-----------
Also, the section "Standard Meta-objects" says "The class named
standard-object is an instance of the class standard-class and is a
superclass of every class that is an instance of standard-class except
itself." I believe that the MOP (p 3-10) contradicts this statement,
since the class structure-object is an instance of the class
standard-class, yet it doesn't have standard-object as a superclass.
[The previous paragraph seems related to my other message. It seems
like there are some exceptions to the general rules that are not clearly
spelled out. There is a general rule that for instances of
standard-class, all superclasses have to have the same metaclass; but
the implied superclass T is an exception. There is a general rule that
all instances of standard-class include standard-object as a superclass;
but structure-class is an exception.]
∂13-Apr-88 1318 Common-Lisp-Object-System-mailer Chapter 1 and 2 Last Chance Review
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 13 Apr 88 13:18:36 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA03659; Wed, 13 Apr 88 16:18:16 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA00841; Wed, 13 Apr 88 16:19:25 EDT
Message-Id: <8804132019.AA00841@mist.UUCP>
To: common-lisp-object-system%sail.stanford.edu@multimax
Subject: Chapter 1 and 2 Last Chance Review
Date: Wed, 13 Apr 88 16:19:19 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Comments on Chapters 1 and 2 of the CLOS Spec (Edition of 2/8/88)
Page 1-9, Add to the list of things provided by slot options and
class options:
o Specifying the legal data types of the slot contents.
(Of course, this can be found elsewhere in the document,
but my impression on reading this introductory list was
that for some reason you couldn't do this.)
Page 1-11, Paragraphs 3 and 7
Why are reader, writer, and with-slots *required* to be
implemented using SLOT-VALUE? I don't doubt that you have
a good reason, but it's not obvious to a relative novice.
Paragraphs 7 and 8
This implies that WITH-SLOTS can access slots without
accessors but WITH-ACCESSORS can't. This is reasonable
but should probably be made explicit. Some people may
feel that this maked WITH-SLOTS unsafe.
Page 1-13, Paragraph 4
This paragraph appears self-contradictory. I think that
it means that portable code cannot depend on slot types
since:
(1) Some implementations may not provide type errors
(therefore reducing the value of slot types for
debugging), and
(2) Calls from outside the package may store incorrect
types (so even if your portable code is self-consistent
you could wind up with undetected type errors).
The wording of this paragraph leads me to suspect that
this issue has already been argued to death on the CLOS list.
Page 1-26, Paragraph 2, Sentence 2
The following are my exact notes as I read this section:
What about methods in both old and new? Are they "added"?
If so, in what way is this definition different from
saying that the "contents" of the old generic function are
trashed and replaced by the new generic function? AHA!
Some methods could have been defined by DEFMETHOD, but the
wording is still confusing.
Paragraph 6, Sentence 3
The wording is a bit confusing.
Page 1-28, Paragraph 2, Sentence 4 and example line
Has this been submitted to cleanup? I don't recognize it.
Page 1.29, Paragraph 1
The wording implies that:
(EQUAL '(A (B C)) '((A B) C))
is T, which is certainly false. Note that cleanup is
entertaining proposal to flush EQUAL and EQUALP.
Page 1-32, At this point I made a note:
In general, this draft details the complex, general case
before the simpler, common special case. This *may* be
appropriate for a standards document but it certainly
isn't for a manual.
Page 2-27, Next to last paragraph
Can extension slot options appear more than once in a
single slot description (it appears reasonable, but it's
not clear from this whether it's legal).
Last paragraph
The slot can also be accessed by WITH-SLOTS, since
WITH-SLOTS uses SLOT-VALUE.
Page 2-35, Paragraphs 7 and 8
These paragraphs don't specify how to distinguish a
predicate from the first keyword option since they are
both distinguished by being symbols other than * (or NIL).
∂13-Apr-88 1414 Common-Lisp-Object-System-mailer Chapter 1 and 2 Last Chance Review
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 13 Apr 88 14:14:11 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA04140; Wed, 13 Apr 88 17:13:39 EDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 381660; Wed 13-Apr-88 17:13:02 EDT
Date: Wed, 13 Apr 88 17:12 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Chapter 1 and 2 Last Chance Review
To: pierson%mist@MULTIMAX.ARPA
Cc: common-lisp-object-system%sail.stanford.edu@MULTIMAX.ARPA
In-Reply-To: <8804132019.AA00841@mist.UUCP>
Message-Id: <19880413211239.3.SKEENE@JUNCO.SCRC.Symbolics.COM>
Date: Wed, 13 Apr 88 16:19:19 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Comments on Chapters 1 and 2 of the CLOS Spec (Edition of 2/8/88)
Hey, you actually read it! Thanks for the useful comments.
Page 1-9, Add to the list of things provided by slot options and
class options:
o Specifying the legal data types of the slot contents.
(Of course, this can be found elsewhere in the document,
but my impression on reading this introductory list was
that for some reason you couldn't do this.)
Good idea. (I think originally this section was intended to be an
overview of the more interesting features, but eventually all of the
features got added except for the :type constraint.)
Page 1-11, Paragraphs 3 and 7
Why are reader, writer, and with-slots *required* to be
implemented using SLOT-VALUE? I don't doubt that you have
a good reason, but it's not obvious to a relative novice.
Some background is: we know that any implementation of CLOS will have
to have a primitive that does what SLOT-VALUE does. Otherwise you
couldn't implement readers or writers at all. So we document that
primitive (SLOT-VALUE) so that all implementations give it the same
name, arguments, and behavior, and therefore users can write portable
code that calls it. The goal is to expose the underlying mechanisms
if they are generally useful.
The purpose of WITH-SLOTS is just to be a shortcut syntax for using
SLOT-VALUE all over the place. It's "required" to be implemented with
SLOT-VALUE because that's just the definition of what it does.
As for why readers and writers are "required" to be implemented using
SLOT-VALUE, hmmm, I'm not sure. I don't think there's any reason why
you wouldn't implement readers and writers with SLOT-VALUE, since
SLOT-VALUE does the thing you want to do.
Paragraphs 7 and 8
This implies that WITH-SLOTS can access slots without
accessors but WITH-ACCESSORS can't. This is reasonable
but should probably be made explicit. Some people may
feel that this maked WITH-SLOTS unsafe.
The implication was intended; that's the difference between the two
macros. I personally agree with people who feel WITH-SLOTS is unsafe.
We could add a sentence to imply what we mean more directly.
Page 1-13, Paragraph 4
This paragraph appears self-contradictory. I think that
it means that portable code cannot depend on slot types
since:
(1) Some implementations may not provide type errors
(therefore reducing the value of slot types for
debugging), and
Yes, it does mean (1). This is also said in the first bullet on page
1-13.
(2) Calls from outside the package may store incorrect
types (so even if your portable code is self-consistent
you could wind up with undetected type errors).
I don't know what you mean by (2).
The wording of this paragraph leads me to suspect that
this issue has already been argued to death on the CLOS list.
(Don't let the wording fool you. We argue every issue to death.)
Page 1-26, Paragraph 2, Sentence 2
The following are my exact notes as I read this section:
What about methods in both old and new? Are they "added"?
If so, in what way is this definition different from
saying that the "contents" of the old generic function are
trashed and replaced by the new generic function? AHA!
Some methods could have been defined by DEFMETHOD, but the
wording is still confusing.
Your point about "some methods could have been defined by DEFMETHOD" is
correct, and we should probably add a sentence to that effect.
Page 1-32, At this point I made a note:
In general, this draft details the complex, general case
before the simpler, common special case.
The section in page 1-32 doesn't present the simpler, common special
case first and then get into details that include the hairy, rare cases.
It does all cases at once. This is a very central part of CLOS, and
it is somewhat complex, so readers are going to have to read the section
on Method Selection and Combination a couple times or more. I think
it's OK as it is.
This *may* be
appropriate for a standards document but it certainly
isn't for a manual.
Right. Manuals have a lot more freedom.
Page 2-27, Next to last paragraph
Can extension slot options appear more than once in a
single slot description (it appears reasonable, but it's
not clear from this whether it's legal).
Last paragraph
The slot can also be accessed by WITH-SLOTS, since
WITH-SLOTS uses SLOT-VALUE.
Do you think we need to say that explicitly? Since WITH-SLOTS is
defined in terms of SLOT-VALUE, I think most readers will figure this
out, as you did.
Page 2-35, Paragraphs 7 and 8
These paragraphs don't specify how to distinguish a
predicate from the first keyword option since they are
both distinguished by being symbols other than * (or NIL).
∂13-Apr-88 1435 Common-Lisp-Object-System-mailer Re: Chapter 1 and 2 Last Chance Review
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 13 Apr 88 14:34:58 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA04246; Wed, 13 Apr 88 17:35:02 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA01079; Wed, 13 Apr 88 17:36:12 EDT
Message-Id: <8804132136.AA01079@mist.UUCP>
To: "Sonya E. Keene" <skeene%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: common-lisp-object-system%sail.stanford.edu@MULTIMAX.ARPA
Subject: Re: Chapter 1 and 2 Last Chance Review
In-Reply-To: Your message of Wed, 13 Apr 88 17:12:00 -0400.
<19880413211239.3.SKEENE@JUNCO.SCRC.Symbolics.COM>
Date: Wed, 13 Apr 88 17:36:10 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
(2) Calls from outside the package may store incorrect
types (so even if your portable code is self-consistent
you could wind up with undetected type errors).
I don't know what you mean by (2).
Let's say you're implementing a window system which has slots
WINDOW-WIDTH and WINDOW-HEIGHT. You define these slots to be of type
integer *and* ensure that your code never puts a non-integer in them.
You still have to explicitly check the type of the slot value every
time any code that you didn't write could have run because a user
program could have put a non-integer in the slot without getting an
error in some implementations.
∂14-Apr-88 0630 Common-Lisp-Object-System-mailer Re: Chapter 1 and 2 Last Chance Review
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 14 Apr 88 06:30:26 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00517; Thu, 14 Apr 88 09:28:40 EDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 382033; Thu 14-Apr-88 09:05:18 EDT
Date: Thu, 14 Apr 88 09:04 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Chapter 1 and 2 Last Chance Review
To: pierson%mist@MULTIMAX.ARPA
Cc: skeene%STONY-BROOK.SCRC.Symbolics.COM@MULTIMAX.ARPA,
common-lisp-object-system%sail.stanford.edu@MULTIMAX.ARPA
In-Reply-To: <8804132136.AA01079@mist.UUCP>
Message-Id: <19880414130455.7.SKEENE@JUNCO.SCRC.Symbolics.COM>
Date: Wed, 13 Apr 88 17:36:10 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
(2) Calls from outside the package may store incorrect
types (so even if your portable code is self-consistent
you could wind up with undetected type errors).
I don't know what you mean by (2).
Let's say you're implementing a window system which has slots
WINDOW-WIDTH and WINDOW-HEIGHT. You define these slots to be of type
integer *and* ensure that your code never puts a non-integer in them.
You still have to explicitly check the type of the slot value every
time any code that you didn't write could have run because a user
program could have put a non-integer in the slot without getting an
error in some implementations.
OK. You're right, you would have to do that if you want to have
portable code. You can do it pretty easily by defining two methods
for the writer generic function yourself (instead of using an
automatically-generated method). One method specializes the new value
parameter on integer (the desired type of value), and writes the value
into the slot. The other method doesn't specialize the new value
parameter, so it gets selected on undesired types of values, and it
signals an error.
Or you could define a before-method on the writer that checks the type
of the new value and signals an error if it isn't an integer. If it is
an integer, the before-method just returns and lets the primary method
write the value into the slot.
If you do this type-checking in methods for accessors, you have to
depend on your clients calling the accessors and not using slot-value.
∂15-Apr-88 1046 Common-Lisp-Object-System-mailer Comment on CLOS
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 15 Apr 88 10:46:35 PDT
Received: from relay2.cs.net by RELAY.CS.NET id an24019; 15 Apr 88 11:25 EDT
Received: from utokyo-relay by RELAY.CS.NET id ar20898; 15 Apr 88 11:14 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA20202; Fri, 15 Apr 88 13:30:41 JST
Received: by aoyama.cc.aoyama.junet (3.2/6.3Junet-1.0)
id AA17656; Fri, 15 Apr 88 13:13:54 JST
Date: Fri, 15 Apr 88 13:13:54 JST
From: Masayuki Ida <ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@aoyama.cc.aoyama.junet>
Message-Id: <8804150413.AA17656@aoyama.cc.aoyama.junet>
To: common-lisp-object-system@SAIL.STANFORD.EDU,
ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET
Subject: Comment on CLOS
I got a mail which is attached at the bottom from Mr. Ohkubo
who is chairing the subcommitte for OOPS under my Jeida
Common Lisp Committee.
My personal opinion is not included here.
But, I feel several of them are agreeable.
I will send my comment in a separate mail.
PLEASE INCLUDE MY NAME IN THE LIST AS "IDA%AOYAMA.JUNET@RELAY.CS.NET".
Thank you.
Masayuki Ida
-------------------------- The mail I got --------------------------------
From ohkubo@pfrad.pf.fujitsu.junet Thu Apr 14 15:32:01 1988
Date: Wed, 13 Apr 88 17:05:24 JST
Subject: Please forward this mail to CLOS mailing-list
Dear Prof. Ida,
Please forward this mail to CLOS mailing-list.
Thanks in advance.
ohkubo
-------------------------------------------------------------------------------
Here are some questions and problems about the CLOS draft. I hope this
will help to refine the CLOS specification.
--- ohkubo
(ohkubo%pfrad.pf.fujitsu.junet@uunet.uu.NET)
1. About the error signaled when next method doesn't exit.
The CLOS spec intends the user should check whether the next method exits
by next-method-p, but it will degrade the modularity, because the user
should concern about his method might have a method with the same name
which discriminate on the super class or combined with method combination.
In the system where multiple inheritance is supported, next method of
some method doesn't mean one unique method. There is a case where same
method have a next method in on case, and there isn't next method in another
case, depending on the context. (On the other hand, in Smalltalk 'super'
method can be decided statically). The method combination facility further
complicates the decision whether next method might be exit. This might
enforce the user should always use next-method-p.
To solve this problem, Object System should call a generic function named
such as 'no-next-method', when call-next-method is invoked but there isn't
such method, and the default method of 'no-next-method' should signal an
error. With this modification user can write 'no-next-method' which does
nothing or invokes error notifier. This mechanism is the same as
'no-applicable-method'.
2. Who and when remove a method defined on 'update-instance-structure'?
Updating instances with class redefinition is important, but the procedure
should be existed temporarily while only updating. With the current
specification, the method defined on 'update-instance-structure' will
become a garbage who will never be called again. Because the class specified
at its parameter-specializer is obsolete after redefining the class, but the
method will last until someone removes it. If user intends to remove the
'obsolete method', he can't have a confidence that the method is obsolete
and never be used agained. Because some implementation might postpone
updating instance until the object will actually be used.
My proposal with this problem, see 3.
3. CLOS doesn't support updating a slot structure.
Update-instance-structure gives chance to revise an instance structure while
redefining class, but it can't be used to revise a slot strucure. For
example, some slot now holding a list and the user find it can be an array
and want to convert slot structure of the existing instances for compacting
memory. In this case, class definition itself need not be changed, so
updating-instance-strucure doesn't be called. If the user redefines the
class with the same class description intentionally, update-instance-
structure can't get proper arguments, because slot name remaines unchanged.
To solve the problems stated at 2 and 3, CLOS should include 'all-instances'
with the same function as 'allInstances' of Smalltalk. I know this is
very difficult for some implementation. But 'all-instances' is very
convenient while maintaining objects in virtual image. It will not be
appropriate to demand 'all-instances' be implemented fast enough as other
lisp functions.
4. CLOS doesn't specify what will be happen when defining an ordinary function
or a macro which has the same name with the existing generic function.
5. When defining a generic function having the same name with the preexisting
ordinary function, current spec says it is error. Is it a proper definition?
In contrast to the case of defgeneric or defmethod, add-method includes the
ordinary function as a default method. What is this rationale? Might it be
rather proper to retain consistency?
6. 'delete-class' and 'delete-generic-function' should be defined.
It isn't easy and isn't clear to delete a class or a generic function as the
case of deleting a structure or a function for the user. It also depends
heavily on each implementation. CLOS should define user interface to
delete a class and a generic function, and also provide sufficient mechanism
for the programmer writing a programming environment.
7. Will it properly work when there are methods with the parameter specializers
whose meta classes are different in one generic function?
8. Introducing private slot.
In classical object systems such as Smalltalk or Flavors, there are methods
they have special semantics for a particular class. This is implied by each
method is belonged to some class. In the methods defined on this class or
its subclasses, instance variables defined in this class are freely
accessible. This makes it possible some slot, which only accessible in some
group of methods, doesn't need to define an accessor. But in CLOS, there
isn't a class which have special semantics for a method. CLOS should provide
the mechanism which allows to access a slot only in some group of methods.
In the current spec, someone want to read a slot and define reader then all
the people can read it.
9. At the first line of page 1-35 in CLOS draft, "Declaring Method Combination"
might be better than "Declarative Method Combinarion". Declarative method
combination means for some reader the demon method such as :before and :after
method, and procedural method combination means 'super', 'run-super', or
'call-next-method'.
-------------------------------------------------------------------------------
∂15-Apr-88 1345 Common-Lisp-Object-System-mailer CLOS comments
Received: from ti.com by SAIL.Stanford.EDU with TCP; 15 Apr 88 13:45:29 PDT
Received: by ti.com id AA14433; Fri, 15 Apr 88 15:43:22 CDT
Received: from Kelvin by tilde id AA27176; Fri, 15 Apr 88 15:44:53 CDT
Message-Id: <2786129024-9418538@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 15 Apr 88 15:43:44 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-lisp-object-system@sail.stanford.edu
Cc: Gray@DSG.csc.ti.com
Subject: CLOS comments
Comments on section 2 of the "Common Lisp Object System Specification"
(X3J13 document 88-002 dated March 1988):
Functionality comments:
-----------------------
DEFCLASS needs to permit a slot option of the form:
(:DOCUMENTATION doc-string)
Any implementation would be permitted to ignore this, but the
standard should recommend that the specified doc-string should become the
value to be returned by the DOCUMENTATION function for any reader methods
created for the slot by the :READER or :ACCESSOR options.
I recognize that an implementation is already permitted to support this as
an extension, but since the use of documentation should be encouraged
rather than made more difficult, I think it is unacceptable to require
users to write code that looks like this:
...
(:READER FOO)
#+(OR TI ...) ; implementations that I happen to know accept this
(:DOCUMENTATION "...")
...
when it is trivial for an implementation to just ignore the option if it
doesn't wish to support it.
It is not apparent why GENERIC-FUNCTION needs to be a special form instead
of a macro.
The CLOS standard should specify that implementations which support it
should include the symbol :CLOS in their *FEATURES* list.
Editorial comments:
-------------------
On page 2-8, the description "... of the form S or of the form S*" is a
little confusing because S is not defined.
I think it would be helpful if locally defined macros and functions (such
as CALL-METHOD and CALL-NEXT-METHOD) had a syntax line that said "Local
Macro" or "Local Function" instead of just "Macro" or "Function".
On page 2-25, third paragraph, the sentence "The slot name argument is a
symbol that can be used as a Common Lisp variable name." is confusing. It
seems to be saying that the name becomes defined such that it can be
accessed just like a variable (as in flavors), but this is only true
through the use of WITH-SLOTS, which is not mentioned here. Probably what
was intended was that the slot name must satisfy the same syntactic
requirements as a variable name, i.e. a symbol which is not a keyword,
nil, or t.
-- David Gray, Texas Instruments
∂21-Apr-88 0707 Common-Lisp-Object-System-mailer some comments on CLOS
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 21 Apr 88 07:06:58 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab16910; 21 Apr 88 8:34 EDT
Received: from utokyo-relay by RELAY.CS.NET id ad06511; 21 Apr 88 7:46 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA04555; Thu, 21 Apr 88 20:02:23 JST
Received: by aoyama.cc.aoyama.junet (3.2/6.3Junet-1.0)
id AA07837; Thu, 21 Apr 88 19:32:30 JST
Date: Thu, 21 Apr 88 19:32:30 JST
From: Masayuki Ida <ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@aoyama.cc.aoyama.junet>
Message-Id: <8804211032.AA07837@aoyama.cc.aoyama.junet>
To: common-lisp-object-system@SAIL.STANFORD.EDU,
ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET
Subject: some comments on CLOS
Comments on CLOS ch1 and ch2.
(since I have been on this list
from two day ago, so I do not know
the current context.)
1. explanation around the mixture of defmethod and defun.
I could not find the specification on the mixture of
defmethod and defun with the same name.
is it error ? is it allowed in what sense?
2. for user convenience, explicit interface of
'make-specializable' in the former version is
better than the current way for doing the same
thing using 'user-added-method' or something.
3. Removal of a class and a method.
how user can remove one method ?
how user can remove a class ?
4. Enumeration in the individual method.
(defmethod foo ((x (eql A)))
...)
(defmethod foo ((x (eql B)))
...)
I have an experience to write
methods which have several sigular
points, and whose bodies are same.
I feel happy if a syntax like,
(defmethod foo ((x (member A B C D)))
...)
which shares the same body for the enumerated
individuals will be in the specificaton.
typos
5. 2-79 symbol-macrolet examples
;;; not (let 'foo (let (('foo 'bar)) 'foo)).
===>
;;; not (list 'foo (let (('foo 'bar)) 'foo)).
↑↑↑↑
Ambiguous
6. 2-8 line 9
Osub1 | ... | Osubn
and line 14
.... for some 1 <= k <= n, ...
'n' is ambiguous to the 'n' of line 13.
====>
line 9
Osub1 | ... | OsubN
and line 14
... for some 1 <= k <= N, ...
replacing small 'n' to large 'N'.
Comment
7. 1-19 to 1-21 Integrating Types and Classes
Fig 1-1.
I prefer 'sequence first rule'.
For instance,
the class precedence list of 'null' should be
(null list symbol sequence t)
or
(null list sequence symbol t)
rather than
(null symbol list sequence t) which
is on Fig 1-1.
How are the discussions on the issue ?
(defmethod foo ((x list))
...)
(defmethod foo ((x symbol))
...)
(foo nil) ?
I feel we cannot absolutely define
the precedence among them.
meta object protocol will solve this problem ?
8. 1-21
pathname and stream should at least be
defined to correspond to classes
independent from the context of 1-21.
(since several file handling are OK for
pathnames and streams)
say,
(defmethod device-analysis ((x pathname))
...)
(defmethod device-analysis ((x stream))
...)
-------
Masayuki Ida